The present application relates to digital communications network traffic session information collection, maintenance and sharing, and more specifically to cross domain session information collection, maintenance and sharing.
A domain, or domain name, is used in digital communications networks, e.g., the Internet, to identify a specific host or site. A domain generally appears in a uniform resource locator (URL), and may be an indicator of the name of the host, the name of a product or service, or another identifier. For example, in the URL www.google.com, Google® is the domain and name of the host.
Due to high traffic either by consumers, businesses, other domains, or various other reasons (collectively referred to as “clients”), many domains have high usage demands. This generally results in a domain owner (e.g., an individual corporation) developing a large network infrastructure including multiple servers for handling incoming requests, data servers for storing information that may be requested by a client, and a load balancer for receiving all incoming client requests and sending the requests to a server that currently has the bandwidth capability to handle the request. To maintain a high level of performance, the network infrastructure may need to expand along with the associated domain usage demands. For example, additional servers may be needed to handle incoming requests and additional data servers may be needed to store data.
Some domains, such as online retailers and auction sites, store session information related to an individual client in one or more session databases. This information may be related to previous actions the client has taken while visiting the domain. For example, if the domain is an online retailer, the session information may include previous purchases, previous queries, and other information associated with the client. The client receives a cookie with a session ID number, and this number is used to retrieve the session information from the session database(s).
FIG. 1 illustrates a traditional domain network infrastructure 100. Various clients 102a-n connect to the domain 100 via a load balancer 104. It should be noted that the infrastructure 100 shown in FIG. 1 is shown by way of example only. Regardless of the actual infrastructure, the clients 102a-n would only communicate with a device configured to receive and route incoming requests such as the load balancer 104. The load balancer 104 routes a request to either server 106a or 106b. For exemplary purposes, the load balancer 104 routes a first request to the server 106a. Based upon any session information contained in the first request (e.g., through a session ID number contained in a header of the first request), the server 106a requests any related session information from database server 108. The database server
The results of the first request are returned to the requesting client (e.g., client 102a) via the load balancer 104. Additionally, updated session information is forwarded from the server 106a to the database 110 via the database server 108. When the same client (e.g., client 102a) makes an additional request, the updated session information is loaded from database 110.
A domain infrastructure such as infrastructure 100 has several problems. One problem is the database server 108 and database 110 must be sized to handle traffic quickly enough such that no bottlenecks occur. As each server 106a and 106b utilizes the same database server 108, the database server must be able to handle a large number of requests. One solution is to use multiple database servers. However, this solution requires multiple databases. In this solution, each database must contain a redundant copy of information such that any session ID, regardless of which database it originated in, is stored and accessible by both database servers. Any communication issues between the two databases, however, will lead to data inconsistencies between stored session information.
Additionally, this solution is single domain oriented. It would be impossible to transfer any incoming requests to another load balancer in an alternate location unless the database server is accessible from the alternate location or a replicated database exists in the alternate location. However, having multiple databases again leads to data consistency issues.